1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for using device certificates for automated authentication of communicating devices.
2. Description of the Related Art
In client-server networking environments, a device functioning as a client generally seeks to locate a device functioning as a server in order to access data (such as a Web page, a traditional flat file, etc.) or perform transactions with application programs executing on the server. Neither clients nor servers typically attempt to locate other clientsxe2x80x94that is, communications are usually established by the client and not by the server. The client typically locates a server that can perform the desired service by issuing a get_host_by_name( ) function call (or equivalent) using a known host name (such as an Internet Protocol, or IP, name), in order to resolve this server host name to a server address (such as an IP address). The get_host_by_name( ) function call causes a query to be issued to a Domain Name System (DNS) service. A DNS server maintains a stored mapping of host names to IP addresses. Upon receiving a query for a particular host name, the DNS server can then return the stored IP address mapped to (i.e. associated with) that host name. These stored mappings are typically statically administered, and therefore it is typically important for a particular host name to have a constant IP address in order to facilitate dynamic access to that host (i.e. server) in a predictable manner that is independent of factors such as the timing of issuing the get_host_by_name( ) call. Traditionally, enabling use of a constant IP address is achieved by statically configuring the server""s IP address at the server itself and at the DNS.
Client and server devices tend to attach to a network dynamically, and remain attached for varying lengths of time. Each such device must obtain a network address (such as an IP address), if it has not already been configured with one, in order to participate in network communications. In local area network (LAN) configurations, it is common practice to dynamically assign an IP address to a device when it connects to the LAN (for instance, when the device powers on). Protocols such as the Bootstrap Protocol (also known as xe2x80x9cBootPxe2x80x9d) and the Dynamic Host Configuration Protocol (commonly known as xe2x80x9cDHCPxe2x80x9d) are often used, among other purposes, to enable automatic dynamic assignment of an IP address to an IP host. (xe2x80x9cHostxe2x80x9d in this context merely refers to a computer device that has the capability of communicating with other computers.) A host requesting an IP address using DHCP is referred to as a xe2x80x9cDHCP clientxe2x80x9d, and the host which implements the DHCP service and responds to such requests is referred to as a xe2x80x9cDHCP serverxe2x80x9d. Similarly, in the BootP protocol the hosts are referred to as xe2x80x9cBootP clientsxe2x80x9d and xe2x80x9cBootP serversxe2x80x9d. The policies and techniques with which the BootP and DHCP protocol implementations manage the assignment of IP addresses to hosts generally differ depending on whether the host is a client or a server. As described above, server addresses are typically statically configured, and constant in value. Thus, the benefits of BootP and DHCP for automatic IP address generation and configuration are therefore not generally available for hosts whose primary function is as a server. Instead, the server""s address must be entered into the server manually, and if the server changes to a different physical location then a different address must be entered. (BootP is defined in the Internet Engineering Task Force""s Request for Comments (RFC) 951, titled xe2x80x9cBOOTSTRAP Protocol (BootP)xe2x80x9d, and DHCP is defined in RFC 1541, titled xe2x80x9cDynamic Host Configuration Protocolxe2x80x9d.)
In view of the advantages of using BootP and DHCP, it would be desirable to enable use of these protocols for servers. Currently, if the physical topology of a LAN is changed, IP addresses of servers previously connected to segments of the changed topology may be no longer valid, and routers will then be unable to route traffic to those invalid addresses. The IP addresses of affected servers must first be changed in the DNS mapping, concurrently with reconfiguring each such server to use its new address. Typically, the reconfiguration of the server is a manual process, and the DNS update may sometimes be a manual process as well. If BootP or DHCP were available for dynamic address assignment to a server when a topology change occurred, this would enable significant improvements in the ability to centrally manage an IP network. For example, the BootP or DHCP service could dynamically manage which P addresses are associated with segments of the physical network, without needing to closely synchronize this activity with the physical location of computers acting in a server role, and without requiring these computers to be reconfigured concurrently with changes to the physical topology. The need for such improvements is compounded by the fact that enterprises (that is, large-scale computing installations and/or computing networks) are moving away from a centralized computing model to a highly distributed model of application deployment. As this move towards distributed computing progresses, more and more systems in the corporate network will take on the capability of performing in a server role. In the absence of automated IP address generation and management (such as that provided by BootP and DHCP), extra effort will be required to administer and manage the IP addresses for this increasing number of servers.
It would be advantageous to dynamically and automatically assign (e.g. using BootP or DHCP) an IP address to a host acting in a server role, such that the server""s IP address would reflect the current IP address definition associated with its host name in the DNS hostname-to-address mapping. Some implementations of this technique are already in practice. However, these known techniques are deficient because of their inability for the network management component to know for sure what device is requesting an IP address assignment. These techniques do not have the capability of preventing a malicious third party from attaching to the network and masquerading as a host that is currently off-line (and is therefore not using its assigned IP address). This deficiency leaves such implementations vulnerable to the masquerading attack. Exploring this scenario in more detail, it would be possible for a malicious individual to program a different computer to simulate the functions of the host under attack, and then to cause a loss of power or a network disconnection such that the original host becomes disconnected or fails, and finally to enable the new (attacking) host to contact a BootP or DHCP server and impersonate the original host. Once an attacking host obtains the DNS identity of the original host by substituting its own IP address into the DNS mapping for the original host""s name, the attacking host is then in a position to perform any number of security attacks (such as a Trojan horse attack, a denial-of-service attack, passing programs containing viruses or other harmful software to users, etc.). Or, the masquerading host could attempt to steal secrets (such as user identification, passwords, and/or private personal data) from users who log on to the masquerading host believing it to be the original host.
Given the current state of the art, it is also easy for an attacker to set up a fake DHCP service (or, similarly, a fake BootP service)xe2x80x94that is, one where the masquerading host assumes the responsibility for, inter alia, assigning IP addressesxe2x80x94thereby opening up an array of additional attacks by which the attacker actually assumes the identity of its victim server host, while the victim is still running. Current art does not provide any way for a DHCP server, before assigning an IP address, to distinguish an authentic requesting host from an attacker. Nor does it provide a means for a requesting host (i.e. a DHCP client) to know that the DHCP server from which it requests an IP address is a true source of valid configuration information. While there have been some suggestions of ways a DHCP server could authenticate a requesting host, such as via a user identification and password transmitted in a HyperText Transfer Protocol (HTTP) flowxe2x80x94which might be protected from third-party tampering using a secure communications exchange such as that provided by the Secure Sockets Layer (SSL) protocolxe2x80x94heretofore all known proposals have involved some kind of authentication occurring above the physical device level.
Accordingly, what is needed is a technique with which the above-described inadequacies in the current art can be overcome.
An object of the present invention is to provide a technique for enabling devices functioning as servers in a network to participate in automatic address assignment mechanisms.
Object of the present invention is to provide this technique in a manner that enables the server requesting an automatically assigned address to be authenticated before assigning an address thereto.
Yet another object of the present invention is to provide this technique whereby the source of an automatically assigned address can be authenticated before the address is used by a server.
Still another object of the present invention is to provide this technique using authentication between pairs of devices at the physical level.
A further object of the present invention is to provide this technique by using a digital certificate and a public/private key pair for a device, where the device is uniquely identified by a device identifier stored in the certificate.
Yet another object of the present invention is to provide a technique for automated authentication of communicating devices, whereby a particular device is authenticated using its device certificate.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, one embodiment of the present invention provides a method, system, and computer program product for using device certificates for automated authentication of communicating devices. In one embodiment, this technique comprises: creating a public key, private key pair for a first device, this key pair adapted for use in public key cryptography systems; creating a first device certificate for the first device, wherein the first device certificate identifies the first device using a device identifier associated with a network adapter card directly attached to the first device; storing the public key in the first device certificate; securely storing the private key on the first device; sending a first message from the first device to a second device; receiving the first message at the second device; authenticating, by the second device, the first device; processing the first message if the authentication determines that the first device is authentic, resulting in creation of a second message; returning the second message from the second device to the first device if the authentication determines that the first device is authentic; and receiving the returned second message at the first device.
Sending the first message may further comprise: digitally signing, by the first device, one or more fields of the first message wherein the one or more fields includes at least the address identifying the first device, using the private key and resulting in creation of a first digital signature; and sending, along with the first message, the first digital signature and the first device certificate. Receiving the first message may further comprise receiving the first digital signature and the first device certificate, in addition to the first message. Authenticating the first device may further comprise: decrypting the received first digital signature using the public key stored the first device certificate; obtaining a certificate authority (CA) public key associated with a CA which created a second digital signature stored in the first device certificate; decrypting the second digital signature using the obtained CA public key; concluding that the first device certificate is authentic if the decrypted second digital signature is authentic; and concluding that the first device is authentic if (1) the decrypted first digital signature is authentic, (2) a device identifier value represented by the decrypted first digital signature matches the address associated with the network adapter card of said first device, and (3) the first device certificate is authentic.
Processing the first message may further comprise digitally signing, by the second device, one or more fields of the resulting second message, using a second private key associated with the second device and resulting in creation of a third digital signature. Returning the second message may further comprise returning, along with the second message: (1) a second device certificate, wherein the second device certificate comprises (a) a second device identifier associated with the second device and (b) a second public key, the second public key associated with the second private key and adapted for use in public key cryptography systems, and (2) the third digital signature. Receiving the returned second message at the first device may also receive the second device certificate and the third digital signature. This technique may also further comprise: decrypting, by the first device, the received third digital signature using the second public key stored in the received second device certificate; obtaining, by the first device, a second CA public key associated with a second CA which created a fourth digital signature stored in the second device certificate; decrypting, by the first device, the fourth digital signature using the obtained second CA public key; concluding that the second device certificate is authentic if the decrypted fourth digital signature is authentic; concluding that the second device is authentic if (1) the decrypted third digital signature is authentic, (2) a third device identifier value represented by the decrypted third digital signature matches the second device identifier, and (3) the second device certificate is authentic; and using the received second message at the first device only if the second device is authentic.
Sending the first message, the first digital signature, and the first device certificate may also send a CA certificate containing the CA public key to the second device using a copy of the CA certificate stored at the first device. In this case, obtaining the CA public key uses the sent CA certificate.
Returning the second message, the second device certificate, and the third digital signature may also return a second CA certificate containing the second CA public key to the first device using a second device copy of the second CA certificate. In this case, obtaining the second CA public key uses the returned CA certificate.
This technique may further comprise: creating a handshaking message by the first device, wherein the handshaking message comprises one or more message fields and a fourth digital signature, wherein the one or more message fields include a time stamp, the fourth digital signature computed over the one or more message fields; sending the handshaking message from the first device to the second device; receiving the handshaking message at the second device; decrypting the fourth digital signature using the public key of the first device; and completing a message exchange initiated by the first message and the second message if the decrypted sixth digital signature is valid and the time stamp is not stale.
Securely storing the private key may store the private key in a write-only memory of the first device, the write-only memory having an ability to perform computations using data values previously stored therein. Or, securely storing the private key might store private key in a read-write memory of the first device, the read-write memory being readable only by means of a shared secret key.
The address identifying the first device in the first device certificate may be a medium access control (MAC) address of the network adapter card.
The technique may further comprise: generating, by the first device, a first challenge; including, by the first device, this first challenge in said one or more fields of the first message; and including, by the second device, the first challenge in said one or more fields of the second message. In this case, using the received second message further comprises using the received second message only if the signed first challenge is valid.
Or, the technique may further comprise: generating, by the first device, a first challenge; including, by the first device, this first challenge in the one or more fields of the first message; generating, by the second device, a second challenge; including the first challenge and the second challenge in the one or more fields of the second message; and including, by the first device, the second challenge in the one or more message fields of the handshaking message. In this case, using the received second message further comprises using the received second message only if the signed first challenge is valid, and completing the message exchange further comprises completing the message exchange only if the signed second challenge is valid.
In another embodiment, this technique comprises: creating a public key, private key pair for a device that will function as a server device, the key pair adapted for use in public key cryptography systems; creating a device certificate for the server device, wherein the device certificate identifies the server device using a device identifier associated with a network adapter card directly attached to the server device; storing the public key in the device certificate; securely storing the private key on the device; sending a first message from a client device to the server device; receiving the first message at the server device; processing, by the server device, the first message, resulting in creation of a second message; returning the second message to the client device; receiving the returned second message at the client device; authenticating the server device; and using the received second message if the authentication determines that the server device is authentic.
Returning the second message may further comprise: digitally signing, by the server device, one or more fields of the second message, using the private key, resulting in creation of a first digital signature; and returning, along with the second message: (1) the device certificate and (2) the first digital signature. Receiving the returned second message at the client device may also receive the device certificate and the first digital signature. Authenticating may further comprise: decrypting, by the client device, the received first digital signature using the public key stored in the received device certificate; obtaining, by the client device, a certificate authority (CA) public key associated with a CA which created a second digital signature stored in the device certificate; decrypting, by the client device, the second digital signature using the obtained CA public key; concluding that the device certificate is authentic if the decrypted second digital signature is authentic; and concluding that the server device is authentic if (1) the decrypted first digital signature is authentic, (2) a device identifier value represented by the decrypted first digital signature matches the server device address, and (3) the device certificate is authentic.
In this embodiment, the server device may be executing a Dynamic Host Configurationxe2x80x94Protocol (DHCP) service, or it might be executing a Domain Name System (DNS) service.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.